Fixups to 2eb16cf (enhancements/update/available-update-metadata:
Propose a new enhancement, 2019-11-19, openshift#123):

* Including two sentences from Clayton about how the CVO sources this
  information and how we build CI/nightly images [1].
* Downcasing in the Go comments, to match the JSON property, following
  the Kubernetes API pattern.
* 'despire' -> 'despite' typo fix.

[1]: openshift/api#521 (comment)

Fixups to 2eb16cf (enhancements/update/available-update-metadata:
Propose a new enhancement, 2019-11-19, openshift#123):

* Including two sentences from Clayton about how the CVO sources this
  information and how we build CI/nightly images [1].

  I think these two sentences are poking holes in the abstraction that
  the CVO is committing to with the new API, and that consumers should
  not have to know or care about these implementation details.
  Clayton feels like they provide useful context about how the system
  works, and that we'll adjust them as necessary if we ever have cause
  to alter the implementation.

* Downcasing in the Go comments, to match the JSON property, following
  the Kubernetes API pattern.

* 'despire' -> 'despite' typo fix.

[1]: openshift/api#521 (comment)

Fixups to 2eb16cf (enhancements/update/available-update-metadata:
Propose a new enhancement, 2019-11-19, openshift#123):

* Including a sentence from Clayton about how we currently `build
  CI/nightly images [1].

  I think this sentence is poking holes in the abstraction that the
  CVO is committing to with the new API, and that consumers should not
  have to know or care about these implementation details.  Clayton
  feels like it provides useful context about how the system works,
  and that we'll adjust them as necessary if we ever have cause to
  alter the implementation.

  I am rejecting his "This URL is set by the 'url' metadata property
  on a release..." suggestion [1], because the enhancement proposal
  includes:

    Then, in the cluster-version operator (CVO), this enhancement
    proposes porting existing logic like available-update translation
    and available-update lookup to preserve the Cincinnati metadata,
    with information from the release image itself taking precedence
    over information from Cincinnati.

  That information will populate url from the release image when the
  release image declares a url (always, for official OpenShift
  releases), but fall back to Cincinnati if it is not set in the
  release.  Clayton's sentence does not talk about the Cincinnati
  fallback possibility.

  I am rejecting his "...should be displayed as a link in user
  interfaces" because interfaces that want to display a link will
  already know that this is their most-generic choice based on the
  other docstring sentences.  But I'm fine including this fragment if
  folks feel like it is adding something useful on its own, with the
  "metadata property on a release" portion removed.

* Downcasing in the Go comments, to match the JSON property, following
  the Kubernetes API pattern.

* 'despire' -> 'despite' typo fix.

[1]: openshift/api#521 (comment)

Fixups to 2eb16cf (enhancements/update/available-update-metadata:
Propose a new enhancement, 2019-11-19, openshift#123):

* Including two sentences from Clayton about how the CVO sources this
  information and how we build CI/nightly images [1,2].

  I think these two sentences are poking holes in the abstraction that
  the CVO is committing to with the new API, and that consumers should
  not have to know or care about these implementation details.
  Clayton feels like they provide useful context about how the system
  works, and that we'll adjust them as necessary if we ever have cause
  to alter the implementation.

* Downcasing in the Go comments, to match the JSON property, following
  the Kubernetes API pattern.

* 'despire' -> 'despite' typo fix.

[1]: openshift/api#521 (comment)
[2]: openshift/api#521 (comment)

Fixups to 2eb16cf (enhancements/update/available-update-metadata:
Propose a new enhancement, 2019-11-19, openshift#123):

* Including two sentences from Clayton about how the CVO sources this
  information and how we build CI/nightly images [1,2].

  I think these two sentences are poking holes in the abstraction that
  the CVO is committing to with the new API, and that consumers should
  not have to know or care about these implementation details.
  Clayton feels like they provide useful context about how the system
  works, and that we'll adjust them as necessary if we ever have cause
  to alter the implementation.

* Downcasing in the Go comments, to match the JSON property, following
  the Kubernetes API pattern.

* 'despire' -> 'despite' typo fix.

[1]: openshift/api#521 (comment)
[2]: openshift/api#521 (comment)

Fixups to 2eb16cf (enhancements/update/available-update-metadata:
Propose a new enhancement, 2019-11-19, openshift#123):

* Including two sentences from Clayton about how the CVO sources this
  information and how we build CI/nightly images [1,2].

  I think these two sentences are poking holes in the abstraction that
  the CVO is committing to with the new API, and that consumers should
  not have to know or care about these implementation details.
  Clayton feels like they provide useful context about how the system
  works, and that we'll adjust them as necessary if we ever have cause
  to alter the implementation.

* Downcasing in the Go comments, to match the JSON property, following
  the Kubernetes API pattern.

* 'despire' -> 'despite' typo fix.

[1]: openshift/api#521 (comment)
[2]: openshift/api#521 (comment)

Fixups to 2eb16cf (enhancements/update/available-update-metadata:
Propose a new enhancement, 2019-11-19, openshift#123):

* Including two sentences from Clayton about how the CVO sources this
  information and how we build CI/nightly images [1,2].

  I think these two sentences are poking holes in the abstraction that
  the CVO is committing to with the new API, and that consumers should
  not have to know or care about these implementation details.
  Clayton feels like they provide useful context about how the system
  works, and that we'll adjust them as necessary if we ever have cause
  to alter the implementation.

* Downcasing in the Go comments, to match the JSON property, following
  the Kubernetes API pattern.

* 'despire' -> 'despite' typo fix.

[1]: openshift/api#521 (comment)
[2]: openshift/api#521 (comment)

Fixups to 2eb16cf (enhancements/update/available-update-metadata:
Propose a new enhancement, 2019-11-19, openshift#123):

* Including two sentences from Clayton about how the CVO sources this
  information and how we build CI/nightly images [1,2].

  I think these two sentences are poking holes in the abstraction that
  the CVO is committing to with the new API, and that consumers should
  not have to know or care about these implementation details.
  Clayton feels like they provide useful context about how the system
  works, and that we'll adjust them as necessary if we ever have cause
  to alter the implementation.

* Downcasing in the Go comments, to match the JSON property, following
  the Kubernetes API pattern.

* 'despire' -> 'despite' typo fix.

[1]: openshift/api#521 (comment)
[2]: openshift/api#521 (comment)

This reacts to the changes in openshift/api#521, which
introduced a new configv1.Release type in the CVO.

This reacts to the changes in openshift/api#521, which
introduced a new configv1.Release type in the CVO.

This reacts to the changes in openshift/api#521, which
introduced a new configv1.Release type in the CVO.

This reacts to the changes in openshift/api#521, which
introduced a new configv1.Release type in the CVO.

This type used to be used for both the admin-provided
spec.desiredUpdate and the operator-provided status.desired.  That
changed in 575f8d2 (config/v1: New Release type for
ClusterVersionStatus, 2019-01-19, openshift#521, 4.6), when status.desired
moved to a new Release type, so now Update is only used for
spec.desiredUpdate.

The properties have been '+optional' since they landed in 898d7e3
(api: Move ClusterVersion/ClusterOperator into config.openshift.io,
2018-11-09, openshift#127) and ab4ff93 (Update ClusterVersion to have a
'force' update flag and track verified, 2019-04-22, openshift#293).

I'm adding 'omitempty', because if the admin doesn't have a particular
version or image in mind, returning explicit empty strings is
distracting noise.  With this commit, it will be easier to focus on
the version or image property that did get set, and you need at least
one of them to be set to be a usable update request.

The force property is a bit more wiggly, since there may be some
benefit to explicitly pointing out that the admin is not forcing the
update.  But forcing is supposed to be an exceptional-situation safety
valve, so I'm adding omitempty there too, because the benefit of
de-emphasizing the property's presence (and reducing the chance that
an admin says "hey, let's see what 'force: true' does" without reading
associated docs) outweighs the benefit of explicitly pointing out
'force: false' cases.